\documentclass[11pt]{article}
\author{Ivan Bogouchev \and Ognian Pertchev \and Gueorgui Tzotchev}
\usepackage[latin1]{inputenc}
\usepackage[francais]{babel}
%\usepackage{fullpage}
\usepackage{graphicx}
\usepackage{verbatim}
\title{FOGE2 le retour}
\frenchspacing
\begin{document}

\maketitle

\centerline{
  Responsable: Christian Queinnec
}

\begin{figure}

\centerline{\includegraphics{upmc}}

\centerline{
  Ma\^itrise d'Informatique
}
\centerline{Fili\`ere Algorithmique et Programmation}

\end{figure}




\pagebreak
\tableofcontents
\pagebreak

\section{Pr\'esentation du TER}

\subsection{Introduction (Foge d'origine)}

FOGE est une librairie Perl, d\'edi\'ee \`a la gestion de questionnaires,
destin\'es pour le WEB. La version d'origine \'etait \'ecrite par Christian
Queinnec pour faciliter le d\'eploiement de questionnaires d'\'evaluation
des enseignements. Par la suite, deux \'etudiants - R\'emi Bantos et David
Haguenauer ont fait une r\'e\'ecriture orient\'ee objet visant \`a rendre la
librairie modulaire, facilitant l'ajout de nouvelles fonctionnalit\'es.

FOGE propose aux cr\'eateurs de questionnaires les objets et
fonctionnalit\'es suivantes:

\begin{enumerate}
\item objets repr\'esentant des questions: selon sa nature une question peut
\^etre repr\'esent\'ee sous forme d'un menu, d'un groupe de cases \`a cocher
(ou boutons radio) ou d'un textfield (ou textarea).

\item objets repr\'esentant des sections - une section dans le vocabulaire
FOGE est une collection de questions, utilis\'ee pour regrouper des
questions concernant le m\^eme sujet.

\item objets repr\'esentant le formulaire - un formulaire dans le
vocabulaire FOGE est une collection de sections. Le formulaire est
l'objet principal d'un questionnaire, capable de servir la page HTML
du questionnaire, ins\'erer les r\'eponses dans une base de donn\'ees,
analyser les r\'eponses pour en extraire des statistiques.

\item objets repr\'esentant des statistiques associ\'ees au questions,
sections et formulaires, proposant plusieurs types de statistiques
(histogrammes, camemberts, ...) choisies par le concepteur du
questionnaire.

\item gestion des droits d'effectuer certaines actions (visualiser le
questionnaire, r\'epondre, voir des diff\'erent type de statistiques) en
fonction de la date courante, l'adresse ip de l'utilisateur ...

\end{enumerate}

Du point de vue des utilisateurs, FOGE offre les fonctionnalit\'es
suivantes: 

\begin{enumerate}
\item g\'en\'erer la page HTML visualisant le questionnaire en respectant la
norme HTML4 et utilisant les CSS. Les messages produits par FOGE (tels
que les noms des boutons, les messages d'erreur, la confirmation de
r\'eception d'une r\'eponse au questionnaire) peuvent \^etre traduits
automatiquement par FOGE. 

\item cr\'eer les tables SQL n\'ecessaires pour le stockage des r\'eponses.

\item isn\'erer dans la base de donn\'ees la \emph{soumission} (par
'soumission' on entend l'ensemble des r\'eponses d'un utilisateur au
questionnaire) en veillant \`a ce que les r\'eponses respectent les
contraintes d\'efinies dans le questionnaire:
  \begin{enumerate}
  \item droit de r\'epondre (ip, utilisateur, date ....)
  \item r\'eponses au questions obligatoires
  \item r\'eponses conformes (\`a une expression r\'eguli\`ere par ex.)
  \end{enumerate}

\item extraire des diverses statistiques sur la r\'epartition des
r\'eponses. (dans FOGE2 les statistiques sont choisies par le concepteur
du questionnaire).

\end{enumerate}

\centerline{\includegraphics{formulaire}}
\subsection{But du TER}
Le but principal de notre projet est d'\'etendre les fonctionnalit\'es de
FOGE, pour permettre aux concepteurs d'un questionnaire d'effectuer
des sondages encore plus exhaustives, de rajouter des outils
statistiques permettant une analyse des donn\'ees plus sophistiqu\'ee et
d'\'etendre les possibilit\'es de d\'efinition des droits d'acc\`es au
formulaire et aux statistiques.

On a donc rajout\'e les fonctionnalit\'es suivantes, d\'ecrites dans la
section 2: 

\begin{description}

\item[filtres] - un filtre permet de restreindre l'ensemble des
informations, extraites de la base de donn\'ees. La restriction se fait
en ne gardant que les r\'eponses associ\'ees \`a une soumission, conforme \`a
certains crit\`eres. (Il s'agit d'une r\'eduction du nombre de n-uplets
dans les relations contenant les r\'eponses).

\item[vues] - une vue permet de restreindre l'ensemble des
  questions. L'utilisateur d\'efinit une vue, en choisissant les
  questions, dont les r\'eponses l'int\'eressent. (R\'eduction du nombre de
  colonnes des relations).

\item[consultation fiche-par-fiche] - une fiche repr\'esente l'ensemble
des r\'eponses d'un \'etudiant au questionnaire. La consultation du vote
fiche-par-fiche exploite les sous-ensembles d\'efinis apr\`es filtrage et
construction de la vue.

\item[s\'ecurit\'e] - concentrer la gestion des droits d'acc\`es dans un module
d\'edi\'e \`a cet effet. D\'efinir formellement les diff\'erents types
d'utilisateurs, groupes d'utilisateurs, ainsi que leurs droits.

\item[nouvelles statistiques] - les statistiques d\'edi\'ees \`a la
recherche d'interd\'ependances entre les r\'eponses des diff\'erentes
questions. 

\item[nouveaux type de questions] - li\'ees logiquement (prendre en
  compte la r\'eponse \`a une des questions seulement si la r\'eponse \`a
  telle autre question est conforme \`a certains crit\`eres.

\item[choisir les statistiques au moment de la consultation] - permettre \`a
un utilisateur de choisir les statistiques qui lui conviennent, au moment
de la consultation.

\item[statut] - cette fonctionnalit\'e permet la consultation des
  param\`etres d'un questionnaire et son \'etat actuel: la date
  d'activation, la date limite (le temps qui reste pour remplir le
  questionnaire), le nombre de soumissions dans la base de donn\'ee au
  moment de la demande de statut.

\item[adaptation] - adapter les parties existantes afin d'utiliser les
  nouvelles fonctionnalit\'es: filtrage, vues, s\'ecurit\'e

\end{description}



\section{Les nouvelle fonctionnalit\'es en d\'etails}

Pour d\'ecrire en d\'etails les extensions apport\'ees, expliquons
bri\`evement comment un script FOGE accomplit ses fonctions de base
(servir la page HTML du questionnaire, ins\'erer les r\'eponses dans la
base de donn\'ees et afficher les statistiques).

Un script FOGE est un script CGI. En tant que tel, il est
lanc\'e par le serveur WEB et re\c coit dans son environnement plusieurs
informations (le query string des m\'ethodes GET et POST de HTTP, l'ip
d'o\`u le formulaire a \'et\'e invoqu\'e ...).

Apr\`es avoir construit toutes les questions et sections ainsi que le
formulaire les contentant, le script FOGE invoque la m\'ethode
\emph{main()} du formulaire.

Apr\`es extraction et analyse des arguments du query string, le
formulaire ex\'ecute l'action demand\'ee. Les m\'ethodes correspondant aux
diff\'erentes actions sont \emph{serve()} (pour servir la page),
\emph{handle\_submission()} (pour g\'erer la soumission) etc.

Quelle que soit l'action demand\'ee, une partie du travail est effectu\'ee
par l'objet repr\'esentant le formulaire, qui de son c\^ot\'e confie le
reste du travail aux sections. De m\^eme,
apr\`es avoir effectu\'e une partie du travail la concernant, la section
distribue le reste du travail aux questions qu'elle contient.

Cette approche modulaire permet de structurer le code et facilite
l'ajout de nouvelles fonctionnalit\'es.

\subsection{Filtres}

Le proc\'ed\'e de filtrage est un outil qui permet de rechercher
avec plus de pr\'ecisions les informations qui nous int\'eressent et de
mettre en \'evidence des r\'esultats qui vont permettre par la suite
d'exploiter mieux les statistiques obtenues.
Les filtres diminuent l'ensemble de recherche, et montrent les
corr\'elations entre les diff\'erentes questions.
Le choix de filtres va affecter la mani\`ere dont les statistiques vont
\^etre calcul\'ees. De ce choix d\'epend, en grande partie, la perception
des r\'esultats.

Un filtre est un objet qui se place entre la base de donn\'ees et les
parties de FOGE qui en extraient des informations (statistiques,
consultations fiche-par-fiche). Il permet de construire des statistiques
pour un sous-ensemble des r\'eponses du questionnaire. Ce sous-ensemble
correspond \`a certains crit\`eres, choisis par l'utilisateur au moment de
la consultation des statistiques.

\subsubsection{Diff\'erents types de filtres}

Les diff\'erents types de filtres choisissent les sous-ensembles associ\'es
selon des crit\`eres diff\'erents. On a impl\'ement\'e deux filtres:

Le premier filtre permet de choisir les soumissions, en fonction des
adresses ip d'origine. Par exemple, \'etant donn\'e un questionnaire
concernant les \'etudiants du campus Jussieu, on aimerait pouvoir
distinguer les soumissions provenant de l'intranet de l'UPMC et celles
provenant de Paris 7.

Le deuxi\`eme filtre, permet de choisir les soumissions, ayant donn\'e
telle ou telle r\'eponse \`a une, plusieurs ou \`a la totalit\'e des
questions. Cela permet de voir la r\'epartition des
r\'eponses dans la sous-ensemble qui satisfait les crit\`eres de
filtrage. 

\subsubsection{Constructions des filtres}

Le crit\`ere de filtrage, pour le FilterIP est une cha\^ine d\'ecrivant une
adresse ip, o\`u on peut utiliser le caract\`ere '*' pour signifier un
groupe d'adresses ip. Par exemple pour les machines du CCE on
pourrait utiliser le filtre construit \`a l'aide de "134.157.116.*".

Pour construire le filtre template, FOGE sert \`a l'utilisateur qui veut
filtrer, la page HTML du questionnaire, telle qu'elle serait servie \`a
un \'etudiant pour remplir le questionnaire, mais avec quelques l\'eg\`eres
modifications: 
\begin{itemize}
  \item le questions \`a choix unique sont devenus des questions \`a
choix multiples.
  \item la r\'eponse \`a toutes les questions est facultative
\end{itemize}

\centerline{\includegraphics{filtre}}

Donc l'utilisateur r\'epondra au parties du questionnaire qui
l'int\'eressent, pour construire un filtre qui va s\'electionner de la
base de donn\'ees seulement les soumissions, qui correspondant \`a la
fa\c con dont l'utilisateur \`a rempli le questionnaire de construction du
filtre. 


\subsubsection{Impl\'ementation}

Pour chaque soumission FOGE stocke dans une table SQL ("foge\_answer") un
identificateur de la soumission, l'adresse ip et le nom du
questionnaire. Pour chaque section du questionnaire, il existe une
table SQL, qui contient les r\'eponses aux questions de la section. Le
premier attribut de cette relation est un identificateur r\'ef\'eren\c cant
l'identificateur de la table "foge\_answer". Ainsi pour avoir les
r\'eponses qu'un \'etudiant a faites (et ensuite calculer les statistiques
dessus), on fait la jointure entre la table foge\_answer, et les tables
des sections su l'attribut id.
Donc pour filtrer, il nous suffit de garder dans la table foge\_answer
(en effet, on cr\'ee un table temporaire, qui masque foge\_answer) les
soumissions qui correspondent aux crit\`eres de filtrage.

Par exemple pour avoir toutes les soumissions, qui ont r\'epondu 'oui' \`a
la question 'Question1' de la section 'Section1', on d\'efinit la table
suivante:

\begin{verbatim}
CREATE TEMP TABLE foge_answer
SELECT f.*
FROM foge_answer f, Section1 s
WHERE f.enquiry="Poll" and f.id = s.id and s.Q1 = "oui";
\end{verbatim}

Donc le crit\`ere de filtrage est traduit en une expression WHERE du
langage SQL.


\subsection{Vues}

Une vue donne acc\`es \`a un sous-ensemble des questions. Elle
permet de pr\'esenter \`a l'utilisateur (et au programmeur) diff\'erentes
perspectives du m\^eme questionnaire. Son utilit\'e se manifeste, surtout
lors du d\'epouillement des statistiques \`a des questionnaire longs, en
permettant de choisir de voir des statistiques sur une (petite) partie
des questions.

Apr\`es avoir d\'efinit la vue qui l'int\'eresse, l'utilisateur peut
visualiser les statistiques, consulter les r\'eponses aux questionnaire
fiche par fiche, ou d\'ecider de d\'efinir un filtre. En tout les cas les
fonctionnalit\'es offertes par FOGE, utiliseront l'ensemble des questions
d\'efinies dans la vue et non celles d\'efinies dans le formulaire.


\subsubsection{Construction des vues}

On a impl\'ement\'e deux fa\c cons de construire une vue. 

La premi\`ere consiste \`a afficher la liste des questions du
formulaire, group\'ees par section et de donner \`a l'utilisateur la
possibilit\'e de choisir celles qui l'int\'eressent (\`a l'aide de cases \`a
cocher, affich\'ees \`a cot\'e des titres des questions).
Initialement toutes les cases sont choisies.


\centerline{\includegraphics{viewgen}}
\clearpage 

L'utilisateur peut s\'electionner les cases associ\'ees aux questions
qui ne l'int\'eressent pas ou directement d\'ecider qu'il n'est pas int\'eress\'e par
toutes les questions d'une section et donc d\'ecocher la case
correspondant \`a la section.


La deuxi\`eme fa\c con de d\'efinir une vue est int\'egr\'ee \`a la consultations
des statistiques associ\'ees aux questions. Apr\`es avoir affich\'e la page des
statistiques pour les questions actuellement choisies, l'utilisateur
peut diminuer l'ensemble des questions (toujours \`a l'aide de cases \`a
cocher) et r\'eafficher la page des statistiques. C\`ad l'affichage des
statistiques et la d\'efinition de la vue sont fait dans la m\^eme page HTML.

\centerline{\includegraphics{statsnviews}}

\subsubsection{Impl\'ementation des vues}

Une vue est un objet PERL, d\'efini dans le module View.pm. Un objet vue
est capable d'initialiser les attributs qui choisissent les questions
importantes, depuis les arguments pass\'es au script par la m\'ethode
POST. Une fois ses attributs initialis\'es, l'objet est capable
d'affirmer quelles sections et questions font partie de la vue (\`a
travers les m\'ethodes contains\_question() et contains\_section()).

Donc d\'esormais, avant de d\'el\'eguer certaines actions \`a une de ses
sections, le formulaire v\'erifie que la section fait partie de la vue
que l'utilisateur a cr\'e\'ee, en invoquant la m\'ethode contains\_section()
de la vue. De m\^eme pour les sections, avant de d\'el\'eguer des actions \`a
une question, la section v\'erifie que la question appartient \`a la vue.


(Est-ce que une partie du code d'initialisation de la vue est
convenable ici?)


(Est-ce que une partie du code montrant l'appel des m\'ethodes serve(),
handle\_submission(), etc des sections par le formulaire et des questions
par les sections est convenable ici)


\subsection{Consultation Fiche-par-Fiche}

La consultation fiche-par-fiche des r\'eponses aux
questionnaire nous permet de voir comment un utilisateur (un \'etudiant)
a rempli la totalit\'e du questionnaire. 

La visite des r\'eponses fiche par fiche est con\c cue afin d'exploiter
les fonctionnalit\'es offertes par les filtres et les vues: c\`ad
l'ensemble des fiches sera compos\'e seulement des r\'eponses qui
satisfont au crit\`eres d\'efinis dans le filtre et chaque fiche
contiendra seulement les r\'eponses aux questions choisies par la vue.

\subsubsection{Comment consulter les r\'eponses}

L'examen du vote fiche par fiche est impl\'ement\'e comme une nouvelle
action effectu\'e par le formulaire. Donc il suffit d'invoquer le script
avec l'argument CGI ``action=fpf''. Bien
\'evidemment on peut avoir d\'ej\`a d\'efini un filtre et/ou une vue.

\subsection{Nouvelles statistiques}
On a rajout\'e un nouveau type de statistiques \`a la batterie de
statistiques que FOGE proposait d\'ej\`a - les stats crois\'ees
(StatsCrossed.pm). Ce type de statistiques est con\c cu pour mettre \`a
l'\'evidence les interd\'ependances (ou montrer qu'il n'y en a pas) des
r\'eponses \`a une question en fonction des r\'eponses \`a une autre question.

\subsubsection{Interpr\'etation de l'information fournie par les StatsCrossed}
A la diff\'erence des autres statistiques, les \texttt{StatsCrossed} ne
sont pas associ\'ees \`a une question, mais \`a deux.
L'information est pr\'esent\'ee sous forme de graphiques \`a barres
empil\'ees. Chaque pile de barres verticales repr\'esente le sous-ensemble
des soumissions, ayant r\'epondu de la m\^eme mani\`ere \`a la d\'euxi\`eme
des deux questions associ\'ees aux statistiques. 


Par example sur la graphique ci-dessous on voit que huit personnes ont
choisi la lettre B\^eta et six d'entre eux pr\'ef\`erent la bi\`ere
japonaise \og Saporo \fg


\centerline{\includegraphics{statscrossed}}


\subsection{Choix dynamique des statistiques}

Il s'agit de donner \`a l'utilisateur la possibilit\'e de choisir et
reconfigurer les statistiques affich\'ees lors de leur
consultation. Cela nous permet de choisir les statistiques en fonction de la
r\'epartition des r\'eponses. Des fois un camembert dit plus qu'un
histogramme.

\subsubsection{Impl\'ementation}



\subsection{La s\'ecurit\'e de FOGE}
FOGE est cr\'e\'e en raison d'\^etre utilis\'e \`a travers des r\'eseaux TCP/IP,
internet en g\'en\'eral, et comme toute application expos\'ee \`a manipulation
d'une publique importante, il doit \^etre bien prot\'eg\'e, c-\`a-d ne pas
laisser la possibilit\'e \`a une personne n'ayant pas les droits
n\'ecessaires de corrompre les donn\'ees et l'application elle-m\^eme.

Avant, les modules de FOGE assuraient une distinction basique des
types d'utilisateurs. Les v\'erifications d'identit\'e se faisaient dans
le module Form qui en g\'en\'eral avait pour but de construire le
formulaire et de traiter les diff\'erents types d'actions que le
questionnaire proposait. Bref, le processus d'identification n'\'etaient
que quelques petites fonctions dans le module Form qui v\'erifiaient que
l'adresse IP appartenait \`a un certain groupe autoris\'e. Ces fonctions
ne prenaient pas en compte le type de l'action demand\'ee, elles
retournaient ou "mourraient"...

L'extension dans cet aspect de FOGE consiste en un nouveau module,
nomm\'e SecurityAgent, ayant pour but d'\'etendre les possibilit\'es de
d\'efinition des droits d'acc\`es et de s'occuper des permissions des
usagers pendant les trois diff\'erentes \'etapes de la dur\'ee de vie d'un
questionnaire.

L'organisation des droits d'acc\`es est r\'ealis\'ee d'une mani\`ere un peu
semblable \`a celle d'unix, c-\`a-d une fois connect\'e un utilisateur est
authentifi\'e soit comme un utilisateur connu, soit comme faisant partie
d'une ou plusieurs groupes, chacun avec des droits sp\'ecifiques. Ainsi
le cr\'eateur du questionnaire peut sp\'ecifier les droits d'acc\`es pour
chaque adresse IP et/ou chaque utilisateur authentifi\'e par un login et
mot de passe, ces derniers obtenus \`a l'aide du protocole https, ou
simplement par une cl\'e de vote, qui assurera l'anonymat du client et
ses r\'eponses uniques (c-\`a-d qu'il n'a pas r\'epondu qu'une seule fois).

En g\'en\'eral il existent trois types d'usagers : - personne(s) avec des
droits d'administration (tous les droits) - personnes qui posent les
questions; eux ayant la possibilit\'e de consulter certaines ou toutes
les statistiques avant la date limite des soumissions.  - personnes
dont on veut l'opinion. (il se peut que la m\^eme personne poss\`ede 2
diff\'erentes identit\'es pour le formulaire - par exemple dans le cas
d'un formulaire ayant pour but de pr\'evoir les r\'esultats des \'elections,
le cr\'eateur du formulaire voudrait voter lui-aussi..)

La dur\'ee de vie d'un questionnaire \'etant limit\'ee en g\'en\'eral, on
distingue trois \'etapes de l'existence d'un questionnaire :

\begin{enumerate}

\item \'Etape 1 : Le questionnaire est mis au point, mais il n'est pas encore
autoris\'e \`a son audience \`a soumettre des r\'eponses. Seules certaines
personnes ont le droit de consulter et \'eventuellement d'apporter des
modifications au formulaire. Ex. : Un professeur pourrait vouloir
ajouter une question portant sur l'examen final au formulaire
d'\'evaluation de la ma\^itrise, mais lors de la cr\'eation du formulaire
l'examen n'est pas encore pr\^et... Les modifications online ne sont pas
(encore) impl\'ement\'es.

\item \'Etape 2 : Le questionnaire est disponible aux
soumissions. Pendant ce temps les diff\'erents utilisateurs pourront
voir les r\'eponses, les statistiques simples, les statistiques avanc\'ees
ou ne rien voir, d\'ependant de leurs droits d'acc\`es.

\item \'Etape 3 : Les
soumissions finies, le formulaire est disponible aux analyses, mais
encore pas tous ont le droit de voir les r\'eponses \`a toutes les
questions.

\end{enumerate}

La raison la plus importante d'apporter les modifications en cr\'eant ce
module n'est pas la besoin d'avoir un syst\`eme avanc\'e d'identification,
mais la complexit\'e de la mani\`ere de choisir quel utilisateur peut voir
quoi et dans quelle p\'eriode. Les droits d'un utilisateur peuvent
changer lors des trois \'etapes de l'existence d'un questionnaire donn\'e,
tandis que les droits d'un autre utilisateur du m\^eme type (voir types
plus haut) peuvent rester les m\^emes ou changer diff\'eremment. Et m\^eme
si cela peut para\^itre rarement n\'ecessaire, il y a des cas o\`u une telle
flexibilit\'e aidera \`a favoriser des questions dont l'on ne voudrait pas
exposer les r\'eponses qu'\`a un certain groupe d'utilisateurs seulement.

Ayant s\'epar\'e de cette mani\`ere le processus d'\'evaluation des droits
d'acc\`es de la construction du formulaire rend la configuration des
droits facilement extensible et mieux param\'etrable.




\subsubsection{Comment d\'efinir les droits d'acc\`es?}
Les droits d'acc\`es sont d\'efinis dans le script de g\'en\'eration du
questionnaire lui-m\^eme, de mani\`ere qu'ils sont fig\'es dedans pour toute
la vie du questionnaire. Ils sont structur\'es sous forme de hachages et
tableaux imbriqu\'es.  En g\'en\'eral les droits se d\'efinissent en cr\'eant
une instance du module SecurityAgent. Cette instance s'initialise avec
les droits sp\'ecifi\'es comme arguments. Son constructeur la remplit avec
le reste des donn\'ees n\'ecessaires pour calculer quelles sont les
actions permises pour un utilisateur donn\'e \`a un instant donn\'e.  Il y
trois cat\'egories de utilisateurs : les super-utilisateurs, les
utilisateurs individuels, et les groupes. Les utilisateurs et les
super-utilisateurs sont authentifi\'es g\'en\'eralement par https. Les
groupes sont surtout des masques IP, mais rien n'emp\^eche des
utilisateurs reconnus pas https d'\^etre associ\'es \`a un groupe. Chaque
cat\'egorie est d\'efinie \`a l'aide d'un tableau. Les droits eux-m\^emes sont
d\'efinis dans deux structures associatives (hachages), en faisant
correspondre \`a tout utilisateur et tout groupe d\'ej\`a d\'efinis un tableau
compos\'e de trois sous-tableaux -  un pour chaque
p\'eriode d\'efinie. Les tableaux imbriqu\'es contiennent les droits
explicitement d\'ecrits par des combinaisons des mots cl\'es : all, none,
submit, simple\_stats, all\_stats etc.  Les dates de d\'ebut et fin des
soumissions sont aussi donn\'ees en arguments.

Voici un exemple d'appel du constructeur de SecurityAgent :


\begin{verbatim}
my $securisation = CGI::FOGE2::SecurityAgent->new
    (
     superusers  => ["root","admin"],
     users       => ["user1", "user2", "127.0.0.1"],
     user_rights => {
	 "user1" => [["none"],                   # etape 1
		      ["submit","simple_stats"], # etape 2
		      ["all_stats"]],            # etape 3

	 "user2" => [["none"],          # etape 1
		     ["all_stats"],     # etape 2
		     ["all_stats"]],    # etape 3
	 
	 "127.0.0.1" =>  [["all"],["all"],["all"]]
	 },
     groups       => ["question_askers","replyers",
		      "gests", "195.137.127.0"],
     group_rights => {
	 "question_askers" => [["all"],           # etape 1
			       ["all_stats"],     # etape 2
			       ["all_stats"]],    # etape 3
	 "replyers"        =>  [["none"],
				["submit","simple_stats"],
				["simple_stats"]],
	 "gests"           => [["none"],
			       ["none"],
			       ["simple_stats"]],
	 "195.137.127.0"   =>  [["all"],["all"],["all"]]
	 },
     submit_date0 =>  ...,
     submit_date1 =>  ...,
     );

\end{verbatim}

L'authentification des utilisateurs se fait soit en analysant
seulement leurs adresses IP, soit en leur demandant de fournir un nom
de login et mot de passe, ceci fait automatiquement par le serveur
Apache, il suffit de lui procurer le fichier .htaccess contenant la
directive ``require valid-user`` dans le r\'epertoire du script
g\'en\'erateur.

Pendant sa cr\'eation, l'instance de SecurityAgent analysera le 'query
string' et effectuera un contr\^ole minimal, qui ne permettra pas aux
utilisateurs de n'ex\'ecuter que les actions qui leurs sont
permises. (De telle mani\`ere est r\'esolu le probl\`eme de la version
pr\'ec\'edente de Foge, qui permettait \`a un utilisateur malin de voir les
mots de passe pour la base de donn\'ees).


\section{Conclusion}

D'un cot\'e le travail r\'ealis\'e nous a confront\'e \`a
diff\'erentes probl\`emes qu'on a su r\'esoudre.

Par exemple le langage de programmation.
Perl \'etant un langage qui n'est pas adapt\'e "\`a la lecture" (m\^eme avec
le souci d'\'ecrire un code lisible et bien comment\'e), la compr\'ehension
du fonctionnement de Foge a demand\'e un effort consid\'erable (encore
plus pour Ognian Pertchev qui d\'ebutait en Perl!).
Une des raisons de choisir ce sujet de TER \'etait
d'approfondir nos connaissances en PERL, BD et programmation CGI.

Et pour l'anecdote, on a m\^eme \'et\'e confront\'es \`a un bug dans Apache,
qu'on a par la suite, trouv\'e document\'e \`a l'adresse 

\emph{"http://nagoya.apache.org/bugzilla/show\_bug.cgi?id=22030"}


D'autre part le travail sur le TER repr\'esente pour nous une exp\'erience
profitable. On a acquis une bonne ma\^itrise de Perl, Postgres et
Apache. On a su respecter les contraintes li\'ees \`a la r\'esolution d'un
probl\`eme concret (contrainte temporelle, de langage, d'int\'egration du
code). C'\'etait aussi l'occasion de travailler en \'equipe - discuter,
combiner des diff\'erentes solutions, trouver la meilleure. Et
finalement on a eu la possibilit\'e de travailler sur un "vrai"
logiciel, de le comprendre, de l'am\'eliorer, et cela sous la direction
de son concepteur!


\end{document}
